Joined Leo in early 1960. Did a few ‘odd jobs’ for Leo ll. In summer was told that I was to lead a small team writing an Intercode Translator for Leo lll. My immediate questions were, "What is Intercode?” "What is a Translator?” With a small team created Intercode translator. Working closely with Master routine (MR) had Translator and its MR interface working in 1961.

Moved to CLEO compiler in 1962 with a larger team.

In 1963 on spent more time accompanying consultants to answer/explain to prospects how Leo software worked.

In 1964 IBM announced 360. Moved to team designing ‘new range’. Abandonment of ‘new range’, after ‘deal’ with RCA for Spectra series. Worked on System 4 and software support until moving to Canada in 1969.

Anyway the RED corner won by a KO and I was instructed to produce a CLEO compiler, for which I was given a somewhat larger team than had been the case with INTERCODE.

2. Why did the CLEO compiler produce output that was input for the Intercode translator? In the initial design stage, the objective was to produce object code ready for handling by the Master Program in the same format as the Intercode Translator; and we had experience of doing this. Inside the team there had been little if any discussion about whether that was the right way to go. Then came the suggestion (from Mike Josephs, I think) that we should go the Intercode route. The argument for going this way was that the CLEO compiler would be ready sooner, both because it would cut down on some of the work that had to be done in earlier passes of the program and because some additional passes would not be required. The argument against was simply that each compile would take longer. I agreed with the Intercode route, on the understanding that we would later be able to amend the compiler to be expanded to incorporate the translator functions. (Of course, this never happened and many members of the team and I were long gone into other roles soon after the Intercode version was working.)

3. High level languages v low level languages and computer road blocks. The pros and cons of this debate have been well versed for many years. What, even now I believe as I swear at my laptop, is an understanding of what is the critical component that slows down the execution of a program. For many years it was the speed of the cpu. In one organisation I became familiar with a critical long running batch program ran every night. The solution was to get faster tape drives. Surprise! the run time of the critical update program did not decrease.